Internet Engineering Task Force (IETF) K. Li 


Request for Comments: 6474 B. Leiba 
Category: Standards Track Huawei Technologies 
ISSN: 2070-1721 December 2011 


vCard Format Extensions: Place of Birth, Place and Date of Death 
Abstract 
The base vCard 4.0 specification defines a large number of 
properties, including date of birth. This specification adds three 
new properties to vCard 4.0: place of birth, place of death, and date 
of death. 
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1. Introduction 


The base vCard 4.0 specification [RFC6350] defines a large number of 
properties, including date of birth. This specification adds three 
new properties to vCard 4.0: place of birth, place of death, and date 
of death. 

1.1. Terminology Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
Syntax specifications shown here use the augmented Backus-Naur Form 
(ABNF) as described in [RFC5234], and are specified as in the base 
vCard specification [RFC6350]. 

2. Identification Property Extensions 

2.1. Property: BIRTHPLACE 
Namespace: 


Property name: BIRTHPLACE 


Purpose: To specify the place of birth of the object the vCard 
represents. 


Value type: A single text value (default) or a single URI value. 
Cardinality: “I1 


Property parameters: VALUE, LANGUAGE 
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Description: 

Format definition: 
BIRTHPLACE-param = "VALUE=" ("text" / "uri") 
BIRTHPLACE-value = text / uri 

; Value type and VALUE parameter MUST match. 

BIRTHPLACE-param =/ altid-param / language-param / any-param 

Examples: 
BIRTHPLACE:Babies’R’Us Hospital 
BIRTHPLACE; VALUE=uri:http://example.com/hospitals/babiesrus.vcf 
BIRTHPLACE; VALUE=uri:geo:46.769307,-71.283079 

2.2. Property: DEATHPLACE 
Namespace: 


Property name: DEATHPLACE 


Purpose: To specify the place of death of the object the vCard 
represents. 


Value type: A single text value (default) or a single URI value. 
Cardinality: *1 
Property parameters: VALUE, LANGUAGE 
Description: 
Format definition: 
DEATHPLACE-param = "VALUE=" ("text" / "uri") 
DEATHPLACE-value = text / uri 
; Value type and VALUE parameter MUST match. 
DEATHPLACE-param =/ altid-param / language-param / any-param 
Examples: 
DEATHPLACE:Aboard the Titanic\, near Newfoundland 


DEATHPLACE; VALUE=uri:http://example.com/ships/titanic.vcf 
DEATHPLACE; VALUE=uri:geo:41.731944,-49.945833 
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2.3. Property: DEATHDATE 
Namespace: 
Property name: DEATHDATE 


Purpose: To specify the date of death of the object the vCard 
represents. 


Value type: The default is a single date-and-or-time value. It can 
also be reset to a single text value. 


Cardinality: “I1 
Property parameters: “VALUE, CALSCALE, LANGUAGE 


CALSCALE can only be present when the value is a 
date-and-or-time value and actually contains a date or date-time. 
LANGUAGE can only be present when the value is text. 


Description: The presence of a DEATHDATE property indicates that the 
subject of the vCard is known to be dead. The absence 
of this property makes no statement one way or the 
other. 


Format definition: 
DEATHDATE-param = DEATHDATE-param-date / DEATHDATE-param-text 


DEATHDATE-value date-and-or-time / text 
; Value type and VALUE parameter MUST match. 


DEATHDATE-param-date = "VALUE=date-and-or-time" / calscale-param 
; calscale-param can only be present when DEATHDATE-value is 
; date-and-or-time and actually contains a date or date-time. 
DEATHDATE-param-date = "VALUE=text" / language-param 
DEATHDATE-param =/ altid-param / any-param 


Examples: 


DEATHDATE:19960415 
DEATHDATE:--0415 

DEATHDATE; 19531015T231000Z 
DEATHDATE; VALUE-text:circa 1800 
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3. “Security Considerations 
The properties defined in this document present no security 
considerations beyond those in Section 9 of the base vCard 
specification [RFC6350]. 

4. IANA Considerations 


TANA has added the following entries to the vCard Properties 
registry, defined in Section 10.3.1 of [RFC6350]. 


+22 ge an Fass TAAS + 

| Namespace | Property | Reference 

+22 +22 4222222222 + 

| | BIRTHPLACE | [RFC6474], Section 2.1 | 
DEATHPLACE [RFC6474], Section 2.2 
DEATHDATE [RFC6474], Section 2.3 

a AE a AGA AAH AA + 
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